fix solo machine proof height sequence mismatch in connection handshake verification #570
Conversation
colin-axner
requested review from
AdityaSripal,
cwgoes and
milosevic
as code owners
| // ICS 003 will not increment the proof height after connection or client state verification | ||
| // the solo machine client must increment the proof height by 2 to ensure it matches | ||
| // the expected sequence used in the signature | ||
| abortTransactionUnless(height + 2 == clientState.consensusState.sequence) |
There was a problem hiding this comment.
Is verify client consensus state always going to be called after 2 previous signature checks? It seems weird to hard code this delta in the verification function itself.
There was a problem hiding this comment.
Did you see the discussion in #562? I agree it is strange to hard code the delta in the verify function and that we cannot guarantee client consensus state verification will always occur in this order , but I don't see a more elegant solution. The proof height incrementing for each verification call is unique to the solo machine and thus cannot be brought into core IBC. Non-unique sequences is misbehaviour for the solo machine. Proof height may be meaningful to core IBC now or later and thus needs to be verified
|
(merging with requisite 2/3 quorum from IBC spec committee) |
ref: #562
Addresses one problem outlined in the issue above. Enforces that the proof height is equivalent to the current client state sequence.
NOTE:
VerifyClientStateis missing from ICS 03-connection as noted in #525. It is assumed that it will be inserted afterVerifyConnectionand beforeVerifyClientConsensusState